Computing refactorings of state machines

For behavior models expressed in statechart-like formalisms, we show how to compute semantically equivalent yet structurally different models. These refactorings are defined by user-provided logical predicates that partition the system's state space and that characterize coherent parts - modes or control states-of the behavior. We embed the refactorings into an incremental development process that uses a combination of both tables and graphically represented state machines for describing system

One evaluation of model-based testing and its automation

Model-based testing relies on behavior models for the generation of model traces: input and expected output - test cases - for an implementation. We use the case study of an automotive network controller to assess different test suites in terms of error detection, model coverage, and implementation coverage. Some of these suites were generated automatically with and without models, purely at random, and with dedicated functional test selection criteria. Other suites were derived manually, with and without the model at hand. Both automatically and manually derived model-based test suites detected significantly more requirements errors than hand-crafted test suites that were directly derived from the requirements. The number of detected programming errors did not depend on the use of models. Automatically generated model-based test suites detected as many errors as hand-crafted model-based suites with the same number of tests. A sixfold increase in the number of model-based tests led to an 11% increase in detected errors

Computing refactorings of state machines

ISSN:1619-1366ISSN:1619-137

Abstract TACoS’04 Preliminary Version Abstractions for Model-Based Testing 1

The idea of model-based testing is to compare the I/O behavior of an explicit behavior model with that of a system under test. This requires the model to be valid. If the model is a simplification of the SUT, then it is easier to check the model and use it for subsequent test case generation than to directly check the SUT. In this case, the different levels of abstraction must be bridged. Not surprisingly, experience shows that choosing the right level of abstraction is crucial to the success of model-based testing. We argue that models for specification purposes, models for test generation, and models for full code generation are likely to be different. The paper classifies and discusses different abstractions. It is intended as a step towards guidelines for those who build behavior models to the end of testing.

White Paper Model-Based Software and Systems Development

The construction of reliable (embedded) software can be significantly improved using explicit model-based toolsupported development process. Research results suggest that such a process can contribute essentially to increase the quality of the developed product as well as to better efficiency of the development itself: • [Jon91] shows that more than 50 % of serious errors are made during design (25 % during implementation); about 30 % of medium class errors are made during design (30 % during implementation) • [Jon91] shows that analytical techniques performed on early-phase description of the product (e.g., structured approaches, design reviews) require generally at least less than 50 % of the effort in both error detection and correction needed for later-phase techniques (e.g., integration test, field test) • [Jon91] shows that those analytical techniques of the early phases are at least twice as effective to detect errors of the early phases than those later-phase techniques. • [BMJ+96] shows that especially in a development process requiring a high level of product quality, CASE support can significantly increase productivity. Therefore, in order to improve both the efficiency of the development process (by increasing the degree of mechanization), and the quality of the development product (by decreasing the amount of possible defects), support for a model-based development for embedded systems should go beyond the following forms o